The random access memory (RAM) of a computing system is typically a fixed-size resource. The RAM must be managed properly to maintain system performance. In run-time environments (e.g., JAVA) the memory management is handled by the system. Memory management includes a process known as garbage collection, which is a process of recycling memory. When a computing program is running it allocates and uses portions of memory on an on-going basis. At some point the program may no longer need to use a particular portion of memory, for example, the memory was allocated for a particular purpose that is no longer relevant. The portions that are no longer being used (garbage) are identified (collected) so that they can be recycled for future use. When garbage collection begins, the garbage collection algorithm must determine all live objects. That is, the garbage collection process marks all objects that are currently being used by the program (live references) and all other objects are considered garbage. The garbage collector (GC) relies on the system compiler to provide a live reference enumeration root set, i.e., live reference information. To provide this information to the GC, the compiler must keep track of which objects should be added to, or deleted from, the live reference information. The live reference information is constantly changing because at different points of program execution some objects are being created and some are no longer used. Typically garbage collection occurs at the time of a function call (call) that requests new memory. A function call passes control to a subroutine and after the subroutine is executed, control returns to the next instruction in the main program. Therefore, to provide the live reference information to the GC, the compiler should be able to determine the live references at each call site. Typically, the compiler stores the live reference information by keeping a list of call sites with corresponding live reference information for each call site stored somewhere in memory. At compilation time, the compiler generates native code to be executed by the computing system and also stores a garbage collection map.
FIG. 1 illustrates a typical storage scheme for live reference information in accordance with the prior art. System 100, shown in FIG. 1, includes native code storage 105 and garbage collection information storage 110. Garbage collection information storage 110 includes method garbage collection information storage 111 that contains a list of all variables for the program and live reference information storage 112. The program contained in native code section 105 consists of a set of instructions, some of which are calls. When the program is being executed and a request for new memory is made (e.g., at a call), the GC inquires of the compiler for a list of live references at that point in the program. So, for example, native code storage 105 contains calls A, B, and C. When garbage collection takes place at one of these calls, the address of the call site at which garbage collection happened is provided to the compiler. The compiler must then go to live reference information storage 112 of garbage collection information storage 110 and traverse the list until the specific address is found. That is, the compiler has to search through the list of all call sites until it finds the one where garbage collection has occurred. At this point the GC has access to the live reference information to perform the garbage collection function.
Storing this information separately taxes the system's processing resources because the live reference information is obtained through a search of what may be a large list. The size of the list depends upon the number of calls in the method. Typically, the list may be indexed to reduce the information access time.